3D Graphics Programming with QuickDraw 3D 1.5.4

Introduction

The 3D Metafile is a file format for 3D graphics applications that makes use of the Apple QuickDraw 3D (QD3D) 1.5 graphics library or other 3D graphics libraries. This document describes the 3D Metafile file format, Version 1.5.

The purpose of the metafile is to establish a standard file format for 3D graphics files. This includes establishing canonical forms for descriptions of familiar 3D graphics objects.

This standard is put forward to promote compatibility among 3D graphics applications and is meant to facilitate the transfer and exchange of data between distinct applications. The file format also permits a project to be saved to a file so that it may be resumed or altered at a later time.

The canonical forms for descriptions of 3D graphics objects outlined in this document embody an object- and class-based approach to 3D graphics. The 3D metafile objects are defined using a small number of basic data types and some object formation devices. Each object is a member of a class; the class structure reflects the structure of the QuickDraw 3D class hierarchy. (But it is worth pointing out that QD3D also supports immediate mode, which does not require creation of objects, and QD3D can write objects in immediate mode.)

Each class of objects, and thus each object, is correlated with a particular node in that structure. We use the terms parent and child to describe the relationships among objects located at immediately adjacent and connected nodes in the structure. For example, a color attribute may be included in a set of attributes that is assigned to a geometric object. In that case, the geometric object is a parent of the attribute set, which in turn is a parent of the color attribute, while the color attribute is a child of the attribute set, which in turn is a child of the geometric object. See the book 3D Graphics Programming With QuickDraw 3D for complete details on this approach to the classification of 3D graphics objects.

A metafile is simply a sequence or list of one or more valid metafile objects. Each metafile must contain exactly one 3D metafile header, and this header must be the first object to occur in the file. Objects following the header may occur in any order permitted by the metafile class hierarchy. Currently, every object that begins in a metafile must be wholly contained in that file; thus, it is not legal to truncate the description of an object at the end of a file.

For examples of complete 3D metafiles, see "Polyhedra" , and "Attribute Arrays" .

A metafile object's data can take two forms:

data that is itself another metafile object
data that is not another metafile object

Collectively the 2nd type of data makes up the root object. The data in a root object is some combination of the basic data types (see "Basic Data Types" ). If a metafile object contains other metafile objects (called subobjects ), then the entire object is enclosed in a container . The first item in the container is the root object, and the subobjects take up the rest of the container. See "Containers" .

This document defines a format for ASCII text files and also defines a format for binary files. The two formats incorporate the same functional features, and there is a close correspondence between their components. Most objects are represented very similarly in the two formats. However, some objects, such as file pointers, are represented differently, as described below. Any text metafile can be converted to a binary metafile, and vice versa, without loss of information.

The metafile file format permits objects to be labeled and referenced: if the same object appears more than once in a metafile, only the first occurrence need be written out fully. All other occurrences take the form of a reference to that first occurrence. The referencing machinery makes use of three special entities: file pointers, reference objects, and table of contents objects. A table of contents provides a complete or partial catalog of the items contained in a metafile. For details, see "File Pointers" , "Reference Objects" , and "Tables of Contents" .

Note that a metafile is not itself a database and does not have the capabilities of a database. Applications that wish to apply the capabilities of a database to the contents of a metafile must connect that file to a preexisting database program.

If desired, the objects in a metafile can be organized by adding them to groups. Almost all objects can be added to one or another of the available groups. Groups are themselves objects, and they can be nested, so that more complex objects can be created that have as much hierarchical structure as desired. See "Groups" .

The strategy of exposition is as follows: we begin with the basic data types. From these we define the defined data types. This is followed by a discussion of abstract (or structural) data types, which are part of the structure of a metafile object. Next is a section containing descriptions of six special metafile objects. This is followed by a section that contains examples illustrating the structure of metafile objects, especially the cross-referencing machinery. The remainder of this document describes the remaining metafile objects.